Imposing the integrity of running software requires the monitoring of all its data during execution, e.g., to ensure it is not modified by a malicious agent. Such integrity monitoring of all data imposes high performance penalties on the protected software and on the execution environment.
Existing techniques that attempt to alleviate the performance impact of integrity measurements or monitoring, either resort to sampling of the monitored data (See, e.g., J. Mai, C.-N. Chuah, A. Sridharan, T. Ye, and H. Zang, “Is Sampled Data Sufficient for Anomaly Detection?,” in Proc. ACM SIGCOMM Conf. Internet Measurement, 2006, pp. 165-176, or see N. Duffield, C. Lund, and M. Thorup, “Properties and Prediction of Flow Statistics from Sampled Packet Streams,” in Proc. ACM SIGCOMM Wkshp. Internet Measurement, 2002, pp. 159-171), or to the use of custom designed hardware [See, e.g., N. Petroni, T. Fraser, J. Molina, and W. A. Arbaugh, “Copilot—a coprocessor-based kernel runtime integrity monitor,” in Proc. USENIX Security Symp., 2004] and instruction set architectures [See, e.g., Y. Fei, “Microarchitectural Support for Program Code Integrity Monitoring in Application-specific Instruction Set Processors,” in Proc. Conf. Design, Automation & Test in Europe, 2007, pp. 1-6; M Milenkovic, A. Milenkovic, and E. Jovanon, “Hardware support for code integrity in embedded processors,” in Proc. Conf. Compilers, Architecture and Synthesis for Embedded Systems, 2005, pp. 55-65; and, W. B. Noble, T. W. Bradley, and M. W. Autry, “Integrity checking procedure for high throughput data transformations”, U.S. Pat. No. 5,586,204].
In the case of sampling, the performance penalty incurred by integrity monitoring is reduced by decreasing the number of trigger events received by the monitor upon data modifications, or by decreasing the number of monitored data elements. Either sampling approach results in a reduction of the performance penalty proportional to the reduction in events received by the integrity monitor. Some hardware-based techniques propose to employ co-processors that can read data from the running software without incurring any additional overhead [See, “Copilo—a coprocessor-based kernel runtime integrity monitor,” referenced herein above].
Other techniques extend the instruction set and micro architectures to automatically augment processors with hardware integrity monitors [See, e.g., “Microarchitectural Support for Program Code Integrity Monitoring in Application-specific Instruction Set Processors,” and “Hardware support for code integrity in embedded processors,” referenced herein above].
There are drawbacks associated with these prior art techniques. The sampling technique suffers from weak security guarantees. By reducing the number of data elements monitored or the frequency with which they are monitored, the chance of catching an attack while it happens is decreased accordingly. Thus, sampling always leads to a reduction in security, often in unpredictable ways. Hardware-based techniques preserve the security of the system, but do so at high incurred costs (since new hardware needs to be added to the system) and in an application-specific way (since the hardware has to be adapted to a specific application domain).
A further problem addressed by integrity monitoring systems is the problem of protecting the integrity of running software in the presence of a malicious agent, e.g., a malicious agent running at the same privilege level. The malicious agent can modify the data over which the protected software operates, thus forcing it to compute incorrect results, to allow access to otherwise unauthorized resources, or to report to the user a state configuration different from the active one.
Existing solutions are part of one or two categories based on their approach to the problem of runtime-integrity protection: Anti-virus (AV) [See, e.g., Symantec AntiVirus, http://www.symantec.com], anti-rootkit [See, e.g., F-Secure BlackLight, http://www.f-secure. com/blacklight/], host intrusion detection systems (HIDS) [See, e.g.,Osiris, http://osiris.shmoo.com/], anomaly detection systems (ADS) [See, e.g., IBM Proventia Network Anomaly Detection System,], and information-flow tainting systems [See, e.g., Yin, H., Song, D., Egele, M., Kruegel, C., and Kirda, E. 2007. Panorama: capturing system-wide information flow for malware detection and analysis. In Proceedings of the 14th ACM Conference on Computer and Communications Security (Alexandria, Va., USA, Oct. 28- 31, 2007). CCS '07; ACM, New York, NY, 116-127) DOI] attempt to identify the malicious agent before it starts executing or while it executes. If these solutions identify the malicious agent, they can shut it down and remove it from the system. These solutions fall short of the stated problem, as they run at the same privilege level as the protected software and the malicious agent. Thus, while they might be able to identify and stop the malicious agent before it affects the protected software, they are open to directed attacks from the malicious agent. Such solutions do not provide the security guarantees required by the problem of runtime-integrity protection. The second set of solutions attempt to reduce the probability of success for an attack by modifying the protected software. Such solutions include memory randomization [See, e.g., PaX Address Space Layout Randomization], data space randomization [See, e.g., Sandeep Bhatkar, R. Sekar. Data Space Randomization. DIMVA 2008: 1-22], and stack and heap protection [See e.g., Hiroaki Etoh and Kunikazu Yoda. Protecting from stack-smashing attacks,), and Microsoft. A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003,].
By their nature, these mechanisms are probabilistic, protect only against simple attacks, and may incorrectly identify benign software as malicious (because these solutions are independent of the protected software).
Further, existing solutions that share the runtime environment with the protected software can thus be compromised by malicious software rendering them inefficient. Solutions that strengthen the protected software or its runtime environment may suffer from false positives.
Thus it would be highly desirable to address the problem of protecting the integrity of running software in computing or data processing environments, e.g., in the presence of a malicious agent running at the same privilege level that can modify the data over which the protected software operates, thus forcing it to compute incorrect results, to allow access to otherwise unauthorized resources, or to report to the user a state configuration different from the active one.